因 head 从 dc689848 → f2496e4e → ff01d1e0 移动触发重跑——上次准入门通过后的新提交修复了 R9-1（方向感知的 ledger 合并）与 R11-1（archive ledger 提交 fence）并补充测试；@wenshao 的第二轮验证在 dc689848 上复现了 R9-1、确认 ff01d1e0 已修复，并批准了当前 head。准入门已针对新 head 重新执行。

模板完整 ✓

问题：已观测到，并非理论性问题。@wenshao 的第二轮报告在 main 上复现了本 PR 所述全部场景的永久辅助残留（包括以零错误返回 alreadyArchived 却令 sidecar 永久滞留的重试路径），并在前一 head 上复现了 R9-1——"新在前"的合并把全部 10 条最新 terminal 挤出 64 条上限，且合并后的 ledger 超过 256 KiB 读取窗口后可见 terminal 变为 0/3。

方向：对齐。这是对 #10179 合入的 daemon session 生命周期机制的正确性修复（替代 #10286）；daemon 在 generation 关闭后仍持有的 writer lease 是比 generation 计数更精确的提交后所有权信号。外部 CHANGELOG 无参考信号（qwen-serve 为内部机制），但该领域完全在范围内。

规模：触及核心路径（packages/core/src/services/**，跨入 packages/cli/src/serve/**）。生产逻辑 595 行（sessionService.ts 255、session-archive.ts 121、standalone-session-service.ts 112、session-writer-lease.ts 107），测试 1247 行，文档 10 行；无生成/schema 文件。500+ 生产行的维护者关注升级现已解除：升级对象已两次以真实环境 A/B 验证本 PR（第二轮恰在本 head 上——三臂对照、变异测试、真实 daemon E2E），并批准了本 head。

方案：范围依然合理——一个所有权原语组合进现有 fence，对所有模糊锁状态保持 fail-closed。上次准入门之后的增量是 R9-1 与 R11-1 及其钉扎测试：均为本 PR 自身评审发现的回归，属于相关工作而非范围蔓延。

风险：无升级风险信号——变更文件均未命中与 revert 相关的高风险路径。

准入门通过。进入代码审查。🔍

因 head 移动到 ff01d1e0 重跑。已完整重读该 head 的生产代码 diff，结论为重新推导，而非沿用旧结论。

代码审查——无阻塞项。 实现比问题陈述所需的最小修复更严格，且方向正确：所有权 fence 在获取租约时以 TOCTOU 抗竞态方式（O_NOFOLLOW 打开、fstat、读前后两次"路径↔描述符"见证）捕获锁文件的 dev/ino 身份，提交后由 assertCleanupOwned() 重新证明；缺失、被替换、损坏、非常规文件或符号链接的锁全部 fail-closed。R9-1 修复已在 diff 中核实：moveLedgerSidecar 方向感知——archive 把较新的 active 半边追加到较旧的 archived 半边之后，unarchive 以原子写把较旧半边置于较新之前，均由新测试钉住（即变异测试中能杀死方向无关变体的 M1）。重试路径已修复：alreadyArchived/alreadyActive 分支现在会在组合 fence 下清理滞留 sidecar，而不再提前返回——这正是 PR 描述里的"永久残留"。standalone 路径将运行时校验与所有权校验组合使用，所有权丢失后跳过附件与暂存目录清理；租约释放的簿记竞态也已修复。复用而非新造机制：unarchive 方向复用现有 atomicWriteFileSync；config.test.ts 的 8 行是租约改为按数字 fd 读锁所必需的 mock 修复，不是顺手改动。

已知未决项——均不阻塞，@wenshao 第二轮结论已按后续项排序：R10-1 经第二轮 A/B 证实与 main 逐字节一致（非本 PR 引入或扩大，作者的语义决定已在案）；archive 方向仍是原地 append（仅重写方向崩溃安全，部分写入重试会重复记录但不丢失）；M2/M3 锁替换测试仍缺（fence 已经 fs 探针证明会触发，只是没有测试钉住）。

测试证据（见上方英文表格）：本 head 的 Qwen Code CI 单测作业在自托管队列排队约 7 小时后、通过全部 34 个 lint/格式门禁、于"运行测试"步骤约 60 分钟时被杀——与上一 head 记录的"损失的运行"模式一致，不是本改动造成的红灯。行为主张不依赖作者自述：依据是 @wenshao 在 Linux 上的第二轮三臂 A/B（真实 daemon、真实文件系统、杀死 R9-1 变异的变异测试，以及合并树上的完整本地门禁）。未落地的是本 head 的仓库单测矩阵——被取消的 ubuntu 作业与跳过的 macos/windows 侧。请手动重跑被取消的 Qwen Code CI 工作流关闭该缺口（flaky patrol 只自动重跑 failure/timed_out，不含 cancelled）；如还需机器人独立复证 fence 语义，可由维护者发起赞助式 @qwen-code /verify（作者无写权限；报告请保持与 fork CI 同等的怀疑——被验证代码是对抗性输入）。

未验证：本 head 的 Windows/Linux 单测侧（矩阵未运行；作者表格两处均标 ⚠️）——由上述重跑覆盖；Linux 上的行为主张由维护者 A/B 覆盖。

置信度：4/5 —— 本 head 审查干净，行为主张已被独立证明；剩下的只有已记录在案的后续项，以及需要手动重跑的 CI 单测矩阵。

回顾。我对这个 bug 的独立方案是转录移动提交后对锁内容做字节级复核；本 PR 做到了这一点，并额外加入了 TOCTOU 抗竞态验证的 inode 身份追踪——更严格，且由"租约被接管"的威胁模型所正当化。上次准入门之后的增量（R9-1 方向感知 ledger 合并、R11-1 archive 提交 fence 及其测试）我重新读过而非轻信修复说明：合并在两个方向上的顺序都正确，重试路径现在会清理滞留 sidecar，而不是返回 alreadyArchived 后撒手不管。评审循环中唯一未决的 Critical（R10-1）已由 @wenshao 的第二轮 A/B 关闭——与 main 逐字节一致，本 PR 既未引入也未扩大，作者的语义决定已在案。评审循环自己的建议是 land-with-residual-risk：出口是维护者的风险接受决定。该决定现已在案：由跑了三臂 A/B、变异测试（R9-1 修复被一个能杀死变异的测试钉住）和真实 daemon E2E 的维护者在本 head 上作出，并已批准。十四轮评审本身也是一个信号：剩余事项是排好序的后续项，不值得再开一轮。

唯一如实的保留：本 head 的 Qwen Code CI 单测步骤未能跑完——在饱和的自托管 runner 上排队约 7 小时后于约 60 分钟被杀，此前作业内全部 lint/格式门禁均绿，macos/windows 侧被跳过。这是一次损失的 CI 运行，不是红灯（同一 SHA 上的兄弟工作流——Serve A/B、no-AK 集成、Desktop Shell、Live Host，以及先前变红的 SDK Java——全部落地为绿），但如果分支保护强制这些检查，合入前需要手动重跑被取消的工作流；flaky patrol 不会重跑 cancelled。若重跑因本 PR 可归因的原因变红，本批准可被撤销。

结论：批准。 以下方被审查提交为锚批准——这是机器人与 @wenshao 已存在的批准并列的一票，分支保护分别计数。这不豁免上述 CI 重跑。

沙箱验证在隔离、无凭证的容器中执行了该 PR 的代码（与 base 构建 A/B 对照、无 mock harness 断言、定向门禁）。仅作为评审证据，不构成评审、批准或 CI 检查。

脚本断言：105 通过 · 0 失败 · 105 总计

抖动门：❌ 2 of 6 changed test file(s) returned different results across identical re-runs (5 full round(s))

确定性抖动门将本 PR 改动的测试文件原样重跑了多轮，得到了不一致的结果（agent 判定：merge-ready）。一个在代码不变时也会失败的测试会以间歇性红灯落在无关的 PR 上，因此无论 agent 判定如何，本次运行按不通过报告——各轮结果矩阵见下方抖动门日志。

PR #10300 Deep Verification — fix(core): Preserve ownership during session cleanup

Verdict: merge-ready — scripted assertions 105 pass / 0 fail (A/B harness, stable across two runs); targeted gates green (core 385 passed | 2 skipped; cli 146 passed); mutation matrix shows every load-bearing guard is pinned by the new tests.
Verified head: 429da3ca863b04479143db8e71dbb1921c7c952d (git rev-parse HEAD^2), merged onto base tip 40c77fce90 (merge commit e894911554, conflict-free).

Central claim and A/B proof

Central claim (PR body): after the primary transcript mutation commits in delete/archive lifecycle operations, auxiliary cleanup (worktree / PR sidecars, prompt ledger, file history, organization) completes iff the daemon still owns the exact writer lease (same inode, byte-identical lock content) — instead of the old runtime-generation fence, which rejected cleanup whenever the generation closed mid-operation and left permanent residue.

Secondary claims: (2) a replaced/invalidated lock after the primary mutation stops auxiliary cleanup with a per-session writer error (fail closed); (3) standalone-session lifecycle composes the same fence with the selected-runtime check.

The harness (harness-ab.mjs) drives the real built SessionService + SessionWriterLease (compiled dist/ of each arm) against a real filesystem sandbox, wiring the options exactly as the daemon does in session-archive.ts (base: assertStorageUnchanged + assertCanMutate; head: plus assertCleanupOwned). "Generation closes right after the primary mutation" is modeled by a self-synchronizing fence keyed on the primary mutation's physical effect; lock tampering is injected at each arm's first post-primary checkpoint (generation-fence call sites on base, cleanup-ownership assertion on head). No mocks anywhere on the code path under test.

Result: 105/105 scripted assertions pass (driver-ab.mjs, expectation table per arm/cell), identical across two runs. Witness: evidence/01-ab-matrix-base-vs-head.png. All five non-nominal cells flip between arms: two (D/A-genclose) from "residue forever" to "cleanup completes" (the fix), three (D-lockswap, D-lockcontent, A-lockswap) from "mutates sidecars with no ownership proof" to "fail closed" (the safety fence). The two nominal cells are byte-equivalent across arms (no regression). Base-cell failures are the expected control outcomes and count as passing assertions.

Reviewer Test Plan, per step: step 1 (generation closes after primary mutation → everything completes) — measured for delete and archive on head (D/A-genclose); unarchive and the two conflict-repair paths share the identical assertCleanupOwned call sites and were verified by code walk, not separate cells. Step 2 (replace/invalidate lock → cleanup stops with per-session writer error) — measured (D-lockswap, D-lockcontent, A-lockswap: SessionWriterLostError, sidecars preserved). Step 3 (standalone through selected workspace runtime checks both runtime identity and lease) — code walk confirms the composition at all four call sites; end-to-end execution not done (see Not covered), and the mutation matrix shows the runtime half of that composition is unpinned (finding below). Step 4 (ordinary behavior unchanged) — D/A-nominal byte-equivalent outcomes on both arms plus the full changed-file gates below.

Findings

S1 (Suggestion, completeness): the runtime-identity half of the standalone composed cleanup check is asserted by no test

The standalone service composes assertCleanupOwned: () => { assertRuntimeCurrent(runtime); lease.assertCleanupOwned(); } at four sites. Mutation VM4b deleted the assertRuntimeCurrent line from one of them and the whole standalone suite stayed green (81/81), while the sibling mutation VM4a (delete the lease.assertCleanupOwned() line) killed exactly one test. So the lease half is pinned; the fail-closed routing half that the PR description's step 3 rests on is not. The runtime behavior itself is correct in code and assertRuntimeCurrent is pre-existing, tested machinery — this is a completeness gap, not a defect: the fixture that would pin it is one that calls the composed callback and asserts the runtime assertion fired. (Mutation-matrix convention: completeness reporting, not a merge condition.)

No higher-severity findings. Specifically checked and not found: callers of archiveSessions/unarchiveSessions/removeSessions that lost a fence (the archive/unarchive cleanup sites call options.assertCleanupOwned?.() without an assertCanMutate fallback — every production caller is routed through session-archive.ts / standalone-session-service.ts, which both pass assertCleanupOwned; the remove path keeps the ?? assertCanMutate fallback for plain callers, which is behavior-identical to base for them); divergent issue/accept ends (the fence is checked where the cleanup executes); lock-tamper shapes beyond swap/rewrite (symlink and byte-identical-rename shapes are pinned by the new lease tests, confirmed non-vacuous via VM1/VM5).

Mutation matrix (vacuity of the new tests)

Unmutated controls green first (core 385 passed | 2 skipped; cli 146 passed). Witness: evidence/02-mutation-matrix.png.

Layered-guard check: VM1 and VM5 each kill tests the other cannot (cleanup-phase assertion vs acquisition/release-phase identity clause) — the two identity checks defend different phases; neither is redundant, and no survivor was misread as vacuity of a guarded hunk. All quoted failures are expected-vs-actual behavioral assertions, not import/compile breakage.

Targeted gates

Not covered

• Per-commit attribution: the checkout is depth 2; only the second commit (429da3ca, "codex: fix CI failure on PR fix(core): Preserve ownership during session cleanup #10300") is reachable — the first (3171d115, the fix itself) sits behind the shallow boundary (git rev-list HEAD^1..HEAD^2 returns 1 vs 2 in the metadata snapshot). The aggregate HEAD^1..HEAD diff is what was verified; which test adjustments belonged to which commit could not be split.
• Trial merge: the workflow's merge commit already places the PR on the current base tip (40c77fce, ahead of the metadata baseRefOid a3ec41a2), conflict-free — so the A/B verifies what actually lands. No separate re-merge was needed; main's delta between the two bases was not itself re-examined.
• Standalone-session lifecycle was not executed end to end (step 3): verified by code walk + mutation characterization only.
• Unarchive-genclose and the two conflict-repair-genclose cells were not run as separate A/B cells; their cleanup paths call the same assertCleanupOwned sites measured for delete/archive.
• Windows behavior: readVerifiedLockIdentity requires a verifiable inode (hasVerifiableInode = ino ≠ 0) for the lock file; this run proves the Linux path end to end. The PR marks Windows/Linux as locally untested (⚠️); on a filesystem returning inode 0 the lease now fails closed at acquisition — consistent with the PR's stated fail-closed intent, but not exercised here.
• Repo-wide test/lint gates were not run (scope: changed files only).
• Replay calibration: N/A — not a workflow/CI PR.

Methodology

Environment: CI verify container (node:22-bookworm), working tree at refs/pull/10300/merge (depth 2), npm ci + npm run build pre-run at HEAD. Base control: git worktree at HEAD^1 with only packages/core rebuilt (scripts/build_package.js, root node_modules reused — PR changes no package.json/lockfile, so the control is dependency-clean; core's nested node_modules symlinked since it is dependency-identical). Harnesses import each arm's compiled dist/ by absolute file URL, so no workspace symlink can cross-contaminate arms; a symbol control confirmed the base dist contains zero assertCleanupOwned/lockFileIdentity occurrences while head contains them. One pre-existing oddity: worktree builds report a single TS7016 (@lydell/node-pty declaration resolution, shellExecutionService.ts — untouched by this PR) yet emit complete JS; it reproduces identically when building base sources, so it is an artifact of building a worktree against the root install, not a PR effect (A/A-equivalent observation). Mutation runs used a scratch worktree at HEAD, rebuilding the mutated package before each run so both relative and package-entry imports saw the mutant; every mutant was restored afterward (tree verified clean). Raw per-cell logs (logs/base-*.log, logs/head-*.log), the driver run (logs/driver-ab-run.txt), mutation logs (logs/vm*.log), build logs, and both harness scripts live in this artifact directory alongside evidence/01-ab-matrix-base-vs-head.png and evidence/02-mutation-matrix.png.

本次验证运行未正常结束，下列内容可能不完整甚至缺失。仅作为评审证据，不构成评审、批准或 CI 检查。

抖动门：⚠️ timeout — the 15-minute budget elapsed before two full rounds completed (0 done) — no flakiness signal either way

维护者验证报告 —— 第二轮，本地真实环境 A/B

我在当前 head 上重新构建了两棵树并重跑了验证，运行平台是 Linux（PR 的测试平台表格里仍标记为 ⚠️ 未测试）。上次报告之后新增的四个 commit 是为了处理 R9-1（阻塞性的 ledger 排序问题），所以本轮的重点放在那里。

结论：R9-1 在 dc689848 上可复现，在 ff01d1e075 上已修复。原有的所有权 fence 结论在新 head 上依然成立。唯一仍未关闭的评审线程（R10-1）所描述的行为，在 main 上逐字节完全一致 —— 本 PR 既没有引入它，也没有扩大它。

1. R9-1 —— 阻塞项可复现，最后四个 commit 已修复

同一个 harness 文件在三个臂里逐字节相同，驱动真实生产入口（unarchiveDaemonSessions / archiveDaemonSessions），跑在真实临时工作区上，使用真实的 SessionService、真实的 SessionArchiveCoordinator 和真实的 acp-bridge ledger reader。没有 mock 任何产品模块。

场景正是 @yiliang114 描述的那个：一次被中断的 unarchive 把较早的 ledger 半边留在了 chats/archive/，随后 session 被复用，较新的 terminal 记录写进了 active 半边。

第三个臂用于隔离这次修复：它就是 PR head，只回退方向感知的合并逻辑，PR 的其他改动全部保持不变。

有两个观测点比原始记录顺序更重要：

• recentPromptTerminalRecords 按文件顺序截取最后 64 条。 当 70 条滞留的旧 terminal 被合并到 10 条新记录之前时，"新在前"的合并会把全部 10 条最新 terminal 挤出 load 响应。修复后 10 条全部保留。
• readRecentPromptTerminals 只读最后 256 KiB。 一旦合并后的 ledger 超过这个窗口，"新在前"的合并会让新记录完全落在窗口之外 —— 可见数量从 3/3 变成 0/3。

danglingInFlightPromptIds 的误报确实存在，但被兜住了：reconcileDanglingPromptTerminals 会跳过任何在列表中已存在 terminal 记录的 promptId，所以我没能让它合成出错误的 terminal，归因守卫是有效的。上面 promptTerminals 的丢失才是没有第二道防线的那部分。

2. 通过真实 qwen serve daemon 的端到端验证

三个臂都返回 200，alreadyActive 信封完全相同，错误数为零。差异对客户端完全不可见，只体现在磁盘上 —— 这正是它需要用文件系统级 A/B 而不是响应断言来验证的原因。

3. 所有权 fence 在新 head 上依然成立

generation guard 的关闭由观察真实文件系统触发 —— 转录一旦离开原路径就关闭 —— 因此复现竞态不依赖调用计数。第 4 行就是 PR 描述里的 "indefinitely"，已确认：在 main 上普通重试返回 alreadyArchived 且零错误，不会再回头处理任何 sidecar。

4. 对新代码的变异测试

M1 是关键：把 moveLedgerSidecar 回退成方向无关的 append 会被两个新增的 reconciliation 测试杀死。 说明 R9-1 不只是被修复，而是被测试真正钉住了。

三个存活的变异，都不是缺陷：

• M2 / M3 —— unarchive 合并内部的 assertCanCommit 以及 source unlink 之前的那次校验没有任何测试覆盖。确定性的 node:fs 故障注入探针（第二张表，与 PR 自己的 ENOSPC 测试用同一个 seam）表明两处 fence 确实会触发：在任一时刻替换锁文件都会抛出 SessionWriterLostError，并且 source 半边逐字节完好。补一个"在合并提交与 source unlink 之间替换锁"的测试就能同时关掉这两个缺口。
• M5 —— readVerifiedLockIdentity 忽略同 inode 原地重写锁记录的变异仍然存活，与上一轮相同。仍不是缺陷：readOwnedLock 和 release 都会重新比较字节内容。

5. 唯一未关闭的评审线程（R10-1）是既有行为

四行结果在两个臂之间完全一致。记录可归属到其他 workspace 的副本依然会被 SessionStorageEntryError 拒绝；只有完全没有所有权证据的副本（空文件，或损坏到无法恢复）才会被删除，而且必须显式传入非默认的 resolveConflicts: true。这与 R6-5 是同一个设计问题，并不是本 PR 引入的回归 —— 因此我认为不应该以它继续阻塞本 PR。如果确实需要改变这个语义，应该作为针对 main 的独立改动。

6. 其余观察

ENOSPC 的不对称是本轮唯一新发现的问题，而且是 nice-to-have，不阻塞：最后几个 commit 重写的那个方向现在是崩溃安全的，另一个方向仍然是原地 append。两种情况都不会丢记录，但重试一次部分完成的 append 会产生重复记录。把 archive 分支也改成原子写就能让两个方向对称，代价只有几行。

上一轮我提出的文档缺口已经补上 —— POST /sessions/archive 现在说明了 alreadyArchived 路径同样需要 lease，与 unarchive 章节一致。

7. 门禁

全部在合并树上执行：

两组失败都是环境问题，我在相同的 worktree 布局下逐一对照了 main：

• core 的那一个失败是 classifies an unreadable owned lock as unavailable。它把锁文件 chmod 0o000 后期望读取失败 —— 而 root 会忽略权限位。这是 fix(core): Fence concurrent ACP session writers #7237 引入的既有测试，在这里对 main 同样失败。
• CLI 的 17 个失败（fast-path、capabilities-docs-contract、run-qwen-serve-live、workspace-agents、workspace-memory、workspace-file-system、conversation-runtime-ownership）在 main 上完全一致地复现 —— 同样 7 个文件、17 失败 / 318 通过。其中没有任何一个是本 PR 修改过的文件。
• 仓库级 npm run build 与 npm run typecheck 都只在 packages/web-shell 失败，原因是本机 node_modules 缺少 @tanstack/react-table。在 main 上是同样的 36 个错误。

关于 CI：变红的 SDK Java job 是 DaemonSessionClientTest 的 HTTP 超时失败。本 PR 没有改动任何 Java 代码，而且同一个 workflow 在同一时间窗口内的多个无关分支上也失败（cx/9437-rewind-stable-identity、feat/8975-channel-state-restore、autofix/issue-10529）。两个 CANCELLED 的 Test job 是被后续 push 取代的。

8. 结论

正确性主张成立，PR 描述的每一个场景都能在 main 上复现缺陷，阻塞性的 R9-1 回归既已修复，也被一个能杀死变异的测试钉住。就我这边而言，当前状态可以合并。

剩下的都是后续项，按我的优先级排序：

1. 把 archive 方向的 ledger 合并改成原子写，与 unarchive 方向对称（§6）。
2. 补上关闭 M2/M3 的锁替换测试（§4）。
3. R10-1 是既有行为（§5）—— 如果确实要改语义，值得针对 main 单开一个 issue，但不应成为阻塞本 PR 的理由。

沙箱验证在隔离、无凭证的容器中执行了该 PR 的代码（与 base 构建 A/B 对照、无 mock harness 断言、定向门禁）。仅作为评审证据，不构成评审、批准或 CI 检查。

脚本断言：464 通过 · 0 失败 · 464 总计

抖动门：⚠️ timeout — only 3 of 5 rounds fit the 15-minute budget; the completed rounds agreed

Sandboxed verification: ✅ passed — merge-ready (agent verdict, follow-up round at a NEW head) — central claim re-proven by live 3-arm A/B, the three delta commits isolated by an intermediate build, previous findings re-measured, flakiness gate re-run clean.

Scripted assertions: 464 passed · 0 failed · 464 total

Flakiness gate: ✅ 4 rounds × 6 changed files = 24/24 P, zero flakes, per-file passed-counts stable across rounds.

Verified head: ff01d1e075d02652380807f0a0e22cdb6c7011ee (git rev-parse HEAD^2), merged onto base tip 02f2101f43 (merge commit aba8ddcd81, conflict-free). This is a follow-up round with a changed head: three commits landed since the previous round verified dc6898484b (4fa1b307, f2496e4e, ff01d1e0 — only the last is individually reachable at this depth-2 checkout). That previous head object IS present locally, so the delta was verified directly: git diff dc689848..ff01d1e0 = 3 files (+182/−7) — moveLedgerSidecar gained the ownership fence inside the ledger merge (archive append guarded, unarchive merge via atomicWriteFileSync(assertCanCommit), source unlink guarded), plus three new tests. All previous measurements were re-executed live at the new head; nothing was carried forward by citation.

Previous-finding status (follow-up round)

Re-measured live at ff01d1e075 — a different head from the previous round (dc6898484b), so every carried measurement was re-executed rather than cited.

Central claim and A/B proof

Central claim (PR body): after the primary transcript mutation commits in delete/archive/unarchive lifecycle operations, auxiliary cleanup (worktree / PR sidecars, prompt ledger, file history, organization) completes iff the daemon still owns the exact writer lease (same inode and byte-identical lock content, verified by readVerifiedLockIdentity) — instead of the old runtime-generation fence, which rejected cleanup whenever the generation closed mid-operation and left permanent residue that a retry never revisits.

Secondary claims: (2) a replaced/invalidated lock after the primary mutation stops auxiliary cleanup with a per-session writer error (fail closed); (3) standalone-session lifecycle composes the same fence with the selected-runtime check; (4) delta: the ledger merge itself is ownership-fenced and unarchive orders the older (archived) half before the newer (active) half, atomically.

The harness (harness-ab.mjs) drives the real built SessionService + SessionWriterLease (compiled dist/ of each arm, imported by absolute file URL) through real filesystem sandboxes (fresh mkdtemp per cell, QWEN_HOME pointed inside it — asserted per cell along with transcript and lock paths). Options are wired exactly as session-archive.ts does (assertStorageUnchanged = lease.assertOwnedAndUnchanged(), assertCanMutate = the generation fence, assertCleanupOwned = lease.assertCleanupOwned() where the arm has it; omitted on base, which has no such option and falls back to assertCanMutate). "Generation closes right after the primary mutation" is a self-synchronizing fence: assertCanMutate observes the primary mutation's physical effect (transcript unlinked / renamed into archive) and throws from the first call after commit — in the two genclose cells only; everywhere else the generation stays open. Lock tampering is injected at each arm's first post-primary checkpoint, so all arms diverge at the same logical instant; the atomic-replace tamper creates the replacement before freeing the old inode (rename-over), because unlink+recreate can get the same inode back, which is legitimately indistinguishable from the original lock. No mocks on the code path under test.

Controls (all scripted):

• Symbol control: base dist contains 0 assertCleanupOwned (sessionService.js + session-writer-lease.js); inter 37+1; head 38+1 (the +1 is the delta's wiring into moveLedgerSidecar).
• Import-closure purity: static import closure of sessionService.js + session-writer-lease.js is 442 (base) / 441 (inter) / 442 (head) files, zero @qwen-code/* imports — no harness path can cross a workspace symlink into another arm's code.
• Realpath controls: each worktree's packages/core/node_modules is the external-deps-only directory (no @qwen-code links); package.json/package-lock.json untouched by the PR, so the shared root install is a clean control.

Result, identical across three official runs: 116 harness assertions per run (base 38, inter 39, head 39; fail=0 each arm — every expectation, including base-cell failures, is encoded arm-aware) plus 32 scripted cross-arm judge checks per run (FLIP/EQUIVALENT, logs/judge-run{1,2,3}.txt). Witness: evidence/01-ab-matrix-base-vs-inter-vs-head.png.

Delta attribution (what the 3-arm buy over a 2-arm): the inter arm carries the whole PR except the final three commits. Every fence-related cell already flips base→inter (lease fence and R-resume reconciliation predate the delta), while L-unarch-order flips only inter→head — base and inter both merge the older half after the newer one, which under the reader's latest-per-promptId semantics leaves p1 dangling in_flight (a completed prompt re-reported as dangling); head orders older-before-newer. The ordering/atomicity fix is load-bearing and belongs exactly to the delta commits.

Reviewer Test Plan, per step: step 1 (generation closes after primary mutation → everything completes) — measured for delete and archive (D/A-genclose); for unarchive, archive/unarchive conflict repair, and committed deletion it is pinned at this head by VM2's 17 kills, which include finishes moving archived sidecars after the generation closes, finishes unarchive conflict cleanup after the generation closes, finishes archive conflict cleanup after the generation closes, and finishes committed deletion cleanup after the generation closes. Step 2 (replace/invalidate lock → cleanup stops with per-session writer error) — measured (D-lockswap / D-lockcontent / A-lockswap, both the new-inode and same-inode-foreign-content shapes) and pinned by VM1's 5 kills (rejects a byte-identical atomic replacement during cleanup, rejects a lock replaced while cleanup ownership is being verified, rejects a symlinked cleanup lock, detects external transcript and lock changes, compares lock identities without losing large inode precision). Step 3 (standalone checks both runtime identity and lease) — composition present at all four call sites (delete L1260, archive L1598, unarchive L1707, committed-deletion recovery L2021); lease half pinned (VM4a killed 3, VM4c killed 1); runtime half unpinned (S1). Step 4 (ordinary behavior unchanged) — D/A-nominal and L-arch-order behavior-equivalent across arms plus the gates below.

Mutation matrix (vacuity of the new tests, delta included)

Un-mutated control green first (standalone suite 89/89, logs/matrix-CONTROL-standalone.log). Witness: evidence/02-mutation-matrix.png; raw logs logs/matrix-*.log; adjudication matrix-check.mjs → 10/10 scripted checks (logs/matrix-check.out). All mutants applied via occurrence-count-asserted patches (mutate.mjs) and restored afterward (final git status --porcelain: clean; core dist rebuilt clean after the two core-mutating rows). All quoted failures are expected-vs-actual behavioral assertions (e.g. VM1: AssertionError: expected function to throw an error, but it didn't), not import/compile breakage.

Layered-guard note for VM10: the unarchive branch still has the assertCanCommit?.() call immediately after the atomic write (before the source unlink), so losing ownership one statement later is still caught — with the observable difference that the destination merge has already committed (retry-safe: the reader is last-writer-wins per promptId, so a re-merge duplicates records idempotently). The VM10 guard narrows the partial-merge window; it is reachable and decidable, so it is not dead code — it is a defense no test asserts.

VM1 count note (vs the previous round's 6): the previous round's broader no-op mutant also induced a lease-helper protocol timeout in keeps the primary lock when reclaim guard cleanup is already complete; this round's clean body-replacement leaves that test passing (746 ms under VM1), so VM1 kills exactly the 5 named behavioral tests. Same fence is pinned; the count difference is mutant shape, not a coverage change.

Targeted gates (at head, 4 rounds, single writer)

Flakiness gate: the six changed test files, run sequentially 4 rounds with a single writer, at head ff01d1e075 (core dist rebuilt clean before the gate). Witness: evidence/03-flakiness-gate-4x6-green.png; per-round logs logs/gate-round*-*.log; adjudication gate-summary.mjs → 10/10 scripted checks (logs/gate-summary.out).

24/24 slots P (P = exit 0 and zero failed tests), zero F, zero infra exits, and every file's passed-count identical across all four rounds. The three previous gate blockers (G1/G2/G3) all remain non-reproducing at this head.

Findings

S1 (Suggestion, completeness, carried from previous rounds — stands, re-measured): the runtime-identity half of the standalone composed cleanup check is asserted by no test

At this head the composed callback

assertCleanupOwned: () => {
  this.options.assertRuntimeCurrent(runtime);
  lease.assertCleanupOwned();
},

appears at four sites in standalone-session-service.ts (delete L1260, archive L1598, unarchive L1707, committed-deletion recovery L2021). Mutation VM4b deleted the assertRuntimeCurrent(runtime) line at all four sites (occurrence-count-asserted patch, 4/4) and the standalone suite stayed green (89/89, exit 0). Reproduce: node tmp/pr10300-verify-20260830-081218/mutate.mjs VM4b && (cd packages/cli && npx --no-install vitest run ./src/serve/conversations/standalone-session-service.test.ts) then node …/mutate.mjs restore. Sibling mutations in the same file prove the harness and suite see the callback (VM4a killed 3, VM4c killed 1) and the unmutated control is green. The behavior itself is correct in code and assertRuntimeCurrent is pre-existing, tested machinery; the missing fixture is one that invokes the composed assertCleanupOwned option with a non-current runtime and asserts the runtime assertion fired. Completeness reporting, not a merge condition.

S2 (Suggestion, completeness, new this round): the unarchive ledger merge's atomic-write assertCanCommit wiring is asserted by no test

No higher-severity findings. No injection-style instructions were found in the PR text.

Not covered

• Per-commit attribution: checkout is depth 2; of the three commits since the previous round only the last (ff01d1e0) is individually reachable (the shallow graft surfaces it alone). The cumulative delta git diff dc689848..HEAD^2 (3 files, +182/−7) is what was verified, and the intermediate build at dc689848 separates the delta from the rest of the PR in the A/B table.
• Standalone-session lifecycle was not executed end to end (Reviewer Test Plan step 3): code walk + mutation characterization only (composition verified at all four sites; lease half pinned, runtime half unpinned).
• Unarchive-genclose and conflict-repair-genclose were not separate A/B cells; they share the assertCleanupOwned checkpoint sites measured for delete/archive, and VM2's 17 kills pin them by name (finishes moving archived sidecars after the generation closes, finishes unarchive conflict cleanup after the generation closes, finishes archive conflict cleanup after the generation closes).
• Partial-merge retry window: losing ownership between the ledger merge commit and the source unlink leaves both files present; a retry re-merges and duplicates records. Not built as an A/B cell; bounded by reading the consumer (packages/acp-bridge/src/prompt-ledger.ts): reconciliation is last-record-per-promptId, explicitly documented as making duplicate writes idempotent on the read side.
• Windows behavior / inode-0 filesystems: hasVerifiableInode returns false for inode 0, and readVerifiedLockIdentity then throws SessionWriterUnavailableError — the lease fails closed at acquisition and at every cleanup check (re-verified by code reading at this head; not exercisable in this container).
• Repo-wide test/lint/typecheck gates not run (scope: the six changed test files only). The two core rebuilds during the matrix (VM8, VM10 arms) compiled with zero tsc errors, and the final clean rebuild at head succeeded.

Methodology

Environment: CI verify container (node:22-bookworm, Node v22.23.2), working tree at refs/pull/10300/merge (depth 2), npm ci + npm run build pre-run at HEAD. Base and intermediate controls: git worktree add tmp/base-tree HEAD^1 and git worktree add tmp/inter-tree dc689848 with only packages/core rebuilt in each (node ../../scripts/build_package.js, root node_modules and the external-deps-only core node_modules symlinked; realpath + no-workspace-link + import-closure checks scripted in closure-scan.mjs and the harness). Harnesses import each arm's compiled dist/ by absolute file URL; each A/B cell runs in its own mkdtemp sandbox with QWEN_HOME pointed inside it. Three official A/B runs (base/inter/head each) plus one captured judge run. Mutation runs edited the PR working tree via mutate.mjs (occurrence-count-asserted patches, all 9 mutants dry-tested apply→restore→CLEAN before the paid runs), ran the affected suite with npx --no-install vitest run, restored via git checkout (tree verified clean at matrix end), and rebuilt core dist clean. The flakiness gate runs the six changed test files sequentially, 4 rounds, single writer. Raw logs (logs/), harness scripts (harness-ab.mjs, judge-ab.mjs, closure-scan.mjs), the mutation patcher (mutate.mjs), the gate runner (gate-run.sh) and checkers (matrix-check.mjs, gate-summary.mjs) live in this artifact directory alongside evidence/01-ab-matrix-base-vs-inter-vs-head.png, evidence/02-mutation-matrix.png, and evidence/03-flakiness-gate-4x6-green.png.